- which had some charm due
> >> to the consistency - but who an i to complain; at least we now have
> >> bitwise operators (for a specific application like roblox it makes
> >> sense but using a dedicated / patched / extended lua machinery in
> >> luate
e only reason why
luajittex is faster than luatex for a tex run is that the vm is faster
due to some limitations (that one can actually hit but in context we
got around it) ... jitting also is cpu dependent and therefore more
fragile futurw wise (more and more complex code too)
[...]
if
behind publisher firewalls
>
> [...]
>
> jitting also costs time and for a single pass process like tex there
> is no gain (we established that long ago alreadY); the only reason why
> luajittex is faster than luatex for a tex run is that the vm is faster
> due to some limitations (tha
lished that long ago alreadY); the only reason why
luajittex is faster than luatex for a tex run is that the vm is faster
due to some limitations (that one can actually hit but in context we got
around it) ... jitting also is cpu dependent and therefore more fragile
futurw wise (more and more c
\contextmark \stopTEXpage
\stopbuffer
\starttext
\contextmark\
\typesetbuffer[Buffer]
\stoptext
I get "MKIV LMTX" when it is processed with context --luatex. I want
the buffer to be processed as MkIV.
Does patching line 691 in buff-ini.lua
template = (jit and "--jit --e
\contextmark\
\typesetbuffer[Buffer]
\stoptext
I get "MKIV LMTX" when it is processed with context --luatex. I want the
buffer to be processed as MkIV.
Does patching line 691 in buff-ini.lua
template = (jit and "--jit --engine=luajittex" or
"--engine=luatex")
Hi,
With luametatex becoming more mature, it's time to get rid of some old
code. For instance, we have lmt files that assume 5.4, but regular lua
files should work for luajittex (5.2) and luatex (5.3). Most noticable
are the lack of bitwise operators and integer devision in luajittex
ple runs could take a while
> (many minutes, iir some 15 depending on how it was run). That was no fun.
>
> In mkiv with luatex and the built in mp library this dramatically went down
> to 18.1 seconds for one run and 14.2 seconds for luajittex, for 428
> pages.
>
> This not
could take
a while (many minutes, iir some 15 depending on how it was run). That
was no fun.
In mkiv with luatex and the built in mp library this dramatically went
down to 18.1 seconds for one run and 14.2 seconds for luajittex, for 428
pages.
This not bad considering that a lots of features
> mtx-context |
> mtx-context | --forcexml force xml stub
> mtx-context | --forcecld force cld (context lua document) stub
> mtx-context | --forcelua force lua stub (like texlua)
> mtx-context | --forcemp forc
hat
the style sets up imposition
mtx-context | --noarrangeignore imposition specifications in
the style
mtx-context |
mtx-context | --jit use luajittex with jit turned off
(only use the faster virtual machine)
mtx-context | --jitonuse luajitt
hat doesn't work out)
luajittex has a limited stack of 8000 so it will also crash
luametatex uses lua 5.4 which uses a bit different stack model and can't
go that high (it has a default of 2000 but i will bnump that to 6000
which still seems to work ok, that way i get upto a 120 maze)
(new lmtx uploa
onsuming backend code, it gets compensated by some optimizations
elswehere, a smaller memory footprint, etc. As no one complains about
performance it doesn't matter much anyway. Unless you used luajittex
there will be no real difference in most cases.
We're in tex live code freeze time so I don't
(probaly not used that much any longer)
luatex|luajittex : mkiv (also the test for luatex dev)
luametatex : lmtx (the (upcoming) real deal)
Mojca and I are diuscussing / working on an upgrade of the context
garden installations and repositories but more about that later,
Will lmtx be available
).
>
> I like this change.
>
>> A more fundamental distinction is between the versions:
>>
>> pdftex|xetex : mkii (probaly not used that much any longer)
>> luatex|luajittex : mkiv (also the test for luatex dev)
>> luametatex : lmtx (the (upcoming)
, effectively nothing changes, apart from the fact that we no longer
use the labels (and distinction on the website).
I like this change.
A more fundamental distinction is between the versions:
pdftex|xetex : mkii (probaly not used that much any longer)
luatex|luajittex : mkiv (also the test
the fact that we no longer
use the labels (and distinction on the website).
A more fundamental distinction is between the versions:
pdftex|xetex : mkii (probaly not used that much any longer)
luatex|luajittex : mkiv (also the test for luatex dev)
luametatex : lmtx (the (upcoming) real deal
==
LuaTeX 1.11.1 2019-10-28
==
First release of luahbtex / luajithbtex,
luatex / luajittex with harfbuzz.
Small bug fixes, code clean up and a couple of new primitives
to match
. This
is only needed when you run into issues. At some point there
might be a split in lua code (for luatex and luametatex) as
5.2 (luajittex, not evolving), 5.3 (luatex, stable frozen)
and 5.4 (luametatex, experimental progressing) have a couple
of different properties that we might want to benefit
0%
> slower). I assume it's regular luatex?
Sorry, this was my fault. I thought I was running luatex and it was
luajittex.
MkIV times with luatex are 51.x seconds, which is a tiny bit faster than
LMTX (52.x seconds). But this is perfectly normal.
>> I’m afraid I can’t be sure that output is t
using luajittex.
I see you use luajittex. What with luatex?
It works perfectly fine with luatex.
So there is some mess up at your end then ... wrong format? There is no
fundamental difference with luajittex (unless making the format fails
but that should be visible). I use lmtx myself but run
On 5/26/19 10:12 PM, Hans Hagen wrote:
> On 5/26/2019 9:52 PM, Pablo Rodriguez wrote:
> [...]
> What if you wipe the whole cache?
I’m afraid it doesn’t work either.
But this is weird. I’m able to typeset whole books from XML sources with
environments using luajittex.
> I see you u
in case it might help,
What if you wipe the whole cache? I see you use luajittex. What with
luatex?
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt
\\ifconditional \\c_page_sides_short ...\
...\
l.3 \\stoptext\
",
["lastluaerror"]="...ce0dde776fb1556f32e/formats/luajittex/lpdf-ini-macro.lua:1029: attempt to call upvalue 'pdfsetpageresources' (a nil value)",
["lasttexerror"]="?&qu
On 5/26/19 10:56 AM, Pablo Rodriguez wrote:
> [...]
> And here the error I get:
>
> lua error > lua error on line 1 in file a.tex:
> ...ce0dde776fb1556f32e/formats/luajittex/lpdf-ini-macro.lua:1029:
> attempt to call upvalue 'pdfsetpageresources' (
Hi Hans,
here is my minimal sample:
\starttext
\input zapf
\stoptext
And here the error I get:
lua error > lua error on line 1 in file a.tex:
...ce0dde776fb1556f32e/formats/luajittex/lpdf-ini-macro.lua:1029:
attempt to call upvalue 'pdfsetpageresources' (a
by multiple users. TEXMFCACHE needs to be writable by the user, so
the natural choice is to set TEXMFCACHE to $HOME/texmf-cache.
We only make an engine distinction (luatex luajittex luametatex) in the
format file not in the cache and that is because the formats can differ but
in other places the suffix
to be writable by the
user, so the natural choice is to set TEXMFCACHE to $HOME/texmf-cache.
We only make an engine distinction (luatex luajittex luametatex) in the
format file not in the cache and that is because the formats can differ
but in other places the suffix makes the difference
doing
- In order to achieve long term stability context will use a lean and
>>> mean variant of luatex (although for now context will keep running on
>>> luatex too; i might drop support for luajittex). Eventually the source
>>> code will be part of the context dist
running on
luatex too; i might drop support for luajittex). Eventually the source
code will be part of the context distribution so that one can always
compile a binary that matches an archived context version.
- This version also permits us to experiment (even very extreme) without
interupting the parent
; luatex too; i might drop support for luajittex). Eventually the source
> code will be part of the context distribution so that one can always
> compile a binary that matches an archived context version.
>
> - This version also permits us to experiment (even very extreme) without
> i
Hi,
So, for those who hesitate to check out lmtx, here is some information.
- In order to achieve long term stability context will use a lean and
mean variant of luatex (although for now context will keep running on
luatex too; i might drop support for luajittex). Eventually the source
code
Hans van der Meer schrieb am 20.03.19 um 18:20:
Last login: Wed Mar 20 08:23:38 on ttys000
Wed Mar 20 18:17:51 CET 2019
21 ~: cdg
22 Genealogie: contexjit family-note.tex
-bash: contexjit: command not found
23 Genealogie:
mmm... contextjit doesn't come with the beta install? Or do I miss
019, at 18:03, Wolfgang Schuster
> wrote:
>
> Henning Hraban Ramm schrieb am 20.03.19 um 17:27:
>> With the latest beta, context --jit stopped working on my Mac (OSX 10.9.5):
>>
>>
>> This is LuajitTeX, Version 1.09.2 (TeX Live 2019/dev)
>> system comma
o the same call?
It shows the same version LuajitTeX 1.09.2
Greetlings, Hraban
---
https://www.fiee.net
http://wiki.contextgarden.net
https://www.dreiviertelhaus.de
GPG Key ID 1C9B22FD
___
If your question is of int
Henning Hraban Ramm schrieb am 20.03.19 um 17:27:
With the latest beta, context --jit stopped working on my Mac (OSX 10.9.5):
This is LuajitTeX, Version 1.09.2 (TeX Live 2019/dev)
system commands enabled.
---!
/Users/hraban/Library/texmf/tex/texmf-cache/luatex-cache/context
With the latest beta, context --jit stopped working on my Mac (OSX 10.9.5):
This is LuajitTeX, Version 1.09.2 (TeX Live 2019/dev)
system commands enabled.
---!
/Users/hraban/Library/texmf/tex/texmf-cache/luatex-cache/context/5fe67e0bfe781ce0dde776fb1556f32e/formats/luatex/cont-en.fmt
ntally, I discovered today (using latest beta from 2019.02.26
20:04) that file hashing may be wrong in ConTeXt. For the sake of
brevity, I only use the 8 first chars.
"sha512sum i-context.pdf" gives c4cc3840. Using luajittex, I get that
result. But using Lua 5.3 (and util-sha.lua), I get
, Joseph Canedo wrote:
> Dear list,
>
> I get a fatal error when using –jit using latest beta.
>
> $ ./build.sh Livre.pdf
>
> [1/1] context --noconsole --jit --errors Livre.tex
>
> FAILED: Livre.pdf
>
> context --noconsole --jit --errors Livre.tex
>
On 2/5/2019 11:31 PM, Joseph Canedo wrote:
Dear list,
I get a fatal error when using –jit using latest beta.
$ ./build.sh Livre.pdf
[1/1] context --noconsole --jit --errors Livre.tex
FAILED: Livre.pdf
context --noconsole --jit --errors Livre.tex
mtx-context | run 1: luajittex
--fmt=&q
Dear list,
I get a fatal error when using –jit using latest beta.
$ ./build.sh Livre.pdf
[1/1] context --noconsole --jit --errors Livre.tex
FAILED: Livre.pdf
context --noconsole --jit --errors Livre.tex
mtx-context | run 1: luajittex
--fmt="c:/ConTeXt/test/tex/texmf-cache/luatex-
On 2/1/2019 10:30 PM, Henri Menke wrote:
Dear list,
ConTeXt allows to select the engine in the preamble with a “magic
comment”. The preamble is parsed and the engine restarted with new
options. The following MWE fails in the latest beta
% engine=luajittex
\starttext
Fail
\stoptext
Dear list,
ConTeXt allows to select the engine in the preamble with a “magic
comment”. The preamble is parsed and the engine restarted with new
options. The following MWE fails in the latest beta
% engine=luajittex
\starttext
Fail
\stoptext
with the error message
texmf-context/scripts
;
>>>
>> it should be fixed in the next beta.
>>
>>
>> I am afraid it is not fixed. The compilation of the wiki example now
>> fails with:
>>
>> lua error > lua error on line 12 in file
>> c://Users/micro/Projects/TeX/ConTeXt/pdfa.tex:
of the wiki example now fails
> with:
>
> lua error > lua error on line 12 in file
> c://Users/micro/Projects/TeX/ConTeXt/pdfa.tex:
> ...ce0dde776fb1556f32e\formats\luajittex/lpdf-ini-macro.lua:236: attempt
> to call global 'pdfsetomitcidset' (a nil value)
>
>
> typo
rror on line 12 in file
c://Users/micro/Projects/TeX/ConTeXt/pdfa.tex:
...ce0dde776fb1556f32e\formats\luajittex/lpdf-ini-macro.lua:236:
attempt to call global 'pdfsetomitcidset' (a nil value)
and in a larger file, I also see:
system > lua > fatal error 1 in file
'C:
.2 had luajittex build disabled
(in April 2018; according to git history I committed the change on the
29th of April 2018). I would say it must have worked in TeX Live 2017,
but I compiled that one with gcc on OpenBSD 6.0/6.1 rather than with
clang. Not that this is a valid excuse though: as shown
.10 for
next texlive 2019, and in our minds "stable" means "in the long term
like pdftex".
In practice this means that luatex comes with lua 5.3.4, that
luajittex uses luajit 2.1 beta3, and that context will assume and support
this setup for a long time. This also means tha
ext':
../../../source/libs/luajit/LuaJIT-src/src/lj_err.c:301: undefined
reference to `_Unwind_RaiseException'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
gmake: *** [Makefile:7713: luaj
ends
> pplib : Paweł Jackowski
> fontforge : George Williams (partial)
> luajit : Mike Pall (used in LuajitTeX)
>
> Compiled with libpng 1.6.35; using 1.6.35
> Compiled with lua version 5.3.5
> Compiled with mplib version 2.00
> Compi
others
lua : Roberto Ierusalimschy, Waldemar Celes and Luiz Henrique de
Figueiredo
metapost : John Hobby, Taco Hoekwater, Luigi Scarso, Hans Hagen and friends
pplib : Paweł Jackowski
fontforge : George Williams (partial)
luajit: Mike Pall (used in LuajitTeX)
Compiled with libpng 1.6.35; us
not found using lookup
'name'
fonts > defining > unknown font
'c:/windows/fonts/SourceHanSans-Regular', loading aborted
xelatex had no problems to use the font.
Is this an error in the font or in the fontloader?
it works ok here with luatex
but ... do you use luajittex?
No (neither with l
> forced type 'otf' of
> >> 'c:/windows/fonts/SourceHanSans-Regular' not found
> >> fonts > defining > font with asked name
> >> 'c:/windows/fonts/SourceHanSans-Regular' is not found using lookup
> >> 'name'
> >> fonts > defining &g
> defining > font with asked name
> >> 'c:/windows/fonts/SourceHanSans-Regular' is not found using lookup
> >> 'name'
> >> fonts > defining > unknown font
> >> 'c:/windows/fonts/SourceHanSans-Regular', loading aborted
> >>
> &
type 'otf' of
>> 'c:/windows/fonts/SourceHanSans-Regular' not found
>> fonts > defining > font with asked name
>> 'c:/windows/fonts/SourceHanSans-Regular' is not found using lookup
>> 'name'
>> fonts > defining > unknown font
>> '
loading aborted
xelatex had no problems to use the font.
Is this an error in the font or in the fontloader?
it works ok here with luatex
but ... do you use luajittex? if so, forget about it as luajit has some
limitations wrr memory and loading tables from stack (adapting the code
to deal
bitwise operators, couldn’t it be?
it's unlikely that that will happen (basically luajit stays 5.2 so
eventualy we might have to drop it) but if you do some extensive testing
you will notice that mkiv with luatex is not that much slower than
luajittex on regular documents (definitely the gap
nuth
>etex : Peter Breitenlohner, Phil Taylor and friends
>omega : John Plaice and Yannis Haralambous
>aleph : Giuseppe Bilotta
>pdftex: Han The Thanh and friends
>kpathsea : Karl Berry, Olaf Weber and others
>lua : Roberto Ierusalimschy, Waldemar Cel
tex : Donald Knuth
etex : Peter Breitenlohner, Phil Taylor and friends
omega : John Plaice and Yannis Haralambous
aleph : Giuseppe Bilotta
pdftex: Han The Thanh and friends
kpathsea : Karl Berry, Olaf Weber and others
lua : Roberto Ierusalimschy, Waldemar Celes and Luiz
Scarso, Hans Hagen and friends
pplib : Paweł Jackowski
fontforge : George Williams (partial)
luajit: Mike Pall (used in LuajitTeX)
Compiled with libpng 1.6.34; using 1.6.34
Compiled with lua version 5.3.4
Compiled with mplib version 2.00
Compiled with zlib 1.2.11; using 1.2.11
Development id
as string.
(4) We keep supporting the bit32 library on top of the new bit operators.
Be aware
of the fact that currently LuajitTeX does not have these operators.
(5) Performance of LuaTeX with Lua 5.3 can be slightly better than with 5.2
but this
really depends on your usage of Lua. In practice
ase
system > 16:
filename=C:/Context/tex/texmf/fonts/opentype/public/lm/lmroman10-regular.otf
foundname=C:/Context/tex/texmf/fonts/opentype/public/lm/lmroman10-regular.otf
fullname=C:/Context/tex/texmf/fonts/opentype/public/lm/lmroman10-regular.otf
usedmethod=direct
system
context/fonts/mkiv/type-imp-texgyre.mkiv usedmethod=database
used file > 10: filename=EBGaramond12-Regular filetype=otf format=otf foundname=/usr/local/texlive/2017/texmf-dist/fonts/opentype/public/ebgaramond/EBGaramond12-Regular.otf usedmethod=database
used file > 11: filename=
s=mkvi engine=luajittex
\setvariables [one]
[a=1,b=1b,c=1c]
\setvariables [two]
[a=2a,b=2,c=2c]
\defineexpandable \Sets
{one,two}
\starttexdefinition unexpanded doInlineTex
other value?
% macros=mkvi engine=luajittex
\setvariables [one]
[a=1a,b=1b]
\setvariables [two]
[a=2a,b=2b]
\define \Sets
{one,two}
\starttexdefinition unexpanded doInlineText #SET
t; You can link musl statically which makes these binaries run basically
> everywhere, so it's actually a win for everybody.
You cannot link musl statically if you use the dynamic linker (dlopen) which is
needed for the FFI
in LuaTeX and LuaJITTeX. Just search online for "musl dlopen&qu
. In that process I noticed that the
setuptex script doesn't
have a shebang but requires bash compatibility. Could you please add
#!/bin/bash
to the script as the very first line?
Also, I only replaced the following binaries:
kpseaccess
kpsestat
kpsewhich
luajittex
luatex
if you use only
s. In that process I noticed that the
setuptex script doesn't
have a shebang but requires bash compatibility. Could you please add
#!/bin/bash
to the script as the very first line?
Also, I only replaced the following binaries:
kpseaccess
kpsestat
kpsewhich
luajittex
luatex
Thus the following bin
runk # ldd build/texk/web2c/luajittex
/lib/ld-musl-x86_64.so.1 (0x7f9814229000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f9814229000)
I could not yet test it because I'd have to create texmf.cnf and formats.
On Sat, 2018-01-20 at 16:13 +1300, Henri Menke wrote:
p/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o):
> In function `lsys_unloadlib':
> /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53-src/src/loadlib.c:122:
> undefined reference to `dlclose'
> collect2: error: ld ret
22:
undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
Makefile:5489: recipe for target 'luatex53' failed
make: *** [luatex53] Error 1
strip: 'build/texk/web2c/luajittex': No such file
strip: 'build/texk/web2c/luatex53': No such file
ls: cannot access 'build/texk/web2c/luaj
opment
>level 6505
>>> I'm not
>>> able to compile the experimental luatex myself anymore. It compiles
>>> luajittex but not luatex.
>>>
>>> My call to build.sh is: sh ./build.sh --jit --parallel 1>compile.log
>>> 2>error.log
>>&g
ld infrastructure and we need to fix the
> existing issues first, but then we could look into it).
>
> (Would you expect any other use besides you?)
Definitely the whole community of the Alpine and Void Linux distributions. The
Alpine people have a build script in their ports tree, but this doe
;> ConTeXt.
>> It is a 1.0.3 from March 2017.
>>
>> 2. first problem would be not a so big one, but since development level 6505
>> I'm not
>> able to compile the experimental luatex myself anymore. It compiles
>> luajittex but not luatex.
>>
>> M
ince development level 6505
> I'm not
> able to compile the experimental luatex myself anymore. It compiles
> luajittex but not luatex.
>
> My call to build.sh is: sh ./build.sh --jit --parallel 1>compile.log
> 2>error.log
>
> I append the error.log.
>
> 3. In
Hi all,
1. the luatex binary for linux armhf is too old for the recent version of
ConTeXt.
It is a 1.0.3 from March 2017.
2. first problem would be not a so big one, but since development level 6505
I'm not
able to compile the experimental luatex myself anymore. It compiles luajittex
: there is a
fundamental low level change in lua (number system) that in some usage
can have consequences. Our (luigi and i) experiences are:
(1) one has to adapt code, but it's often clear when; one also have to
realize that luajittex is a hybrid 5.1/5.2 and some day maybe 5.3
(2) we have done quite some
o other difference.
>
> Sometimes it has its own bugs, like at the moment (at least in last
> week’s beta) with Lua code. Sometimes ConTeXtJIT couldn’t find my
> fonts, where ConTeXt could (maybe an old, solved problem).
And luajittex is not *always* faster, as Hans has shown u
tempt to index
>> local ‘searchers' (a nil value)
> Many thanks for your reply, Floris.
>
> Could you also check your luajittex version?
$ luajittex --version
This is LuajitTeX, Version 1.05.0 (TeX Live 2017)
signature.asc
Description: Message signed with OpenPGP using GPGMai
ntext.mkiv
> mtx-context | current version: 2017.11.01 15:58
>
> $ contextjit --version
> /Applications/ConTeXt/tex/texmf-osx-64/bin/mtxrun:633: attempt to index local
> ‘searchers' (a nil value)
Many thanks for your reply, Floris.
Could you also check your luajittex version?
Man
Are there any implications for the LuaJIT support?
LuaJIT is quite a bit faster than Lua which is why I always typeset my
documents using luajittex.
On Mon, 2017-10-30 at 17:26 +0100, Hans Hagen wrote:
> Hi,
>
> Luigi and I are currently looking into Lua 5.3 in combination with
>
ciated...
I have just uploaded dynamically linked luatex and luajittex.
I hope that you can again load your lua DLL modules in a few days.
Further, standard C functions can be used in ffi without
loading a C DLL. For example, my previous example can
be changed as follows:
%
% context test.tex
%
\sta
Hello Akira,
On Sun, 09 Apr 2017 00:23:48 +0200, Akira Kakuto <kak...@fuk.kindai.ac.jp>
wrote:
Any way to re-enable user DLL loading into ConTeXt, even
in the future, would be appreciated...
I have just uploaded dynamically linked luatex and luajittex.
great news, I'
Any way to re-enable user DLL loading into ConTeXt, even
in the future, would be appreciated...
I have just uploaded dynamically linked luatex and luajittex.
I hope that you can again load your lua DLL modules in a few days.
Further, standard C functions can be used in ffi without
loading a C
ConTeXters,
I am stymied trying to insert characters into a buffer, or failing that,
to back up, removing the \par, and adding characters after the buffer is
loaded.
The code I am working with reduces to this:
1. % macros=mkvi engine=luajittex
2. \starttexdefinition
t makes no sense
For luajit ffi see
http://luajit.org/ext_ffi.html
The main difference with standard luajit is that by default jit.off()
in luajittex.
___
If your question is of interest to others as well, please add an en
tml
>
> The main difference with standard luajit is that by default jit.off()
> in luajittex.
>
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / h
ype function: 0xa4b7e0
>> copy function: 0xa4b7e0
>
>ok, now if you call one function you should see
>
>The ffi module is available for:\n"
>
>archictures : ARCH_X86 and ARCH_X64,\n"
>operating systems : OS_CE, OS_WIN, OS_LINUX, OS_BSD and OS_POSIX
>
&
perating systems : OS_CE, OS_WIN, OS_LINUX, OS_BSD and OS_POSIX
The ARM processor is currently not supported. There are subtle
differences between this module and the one in luajitTeX
and we hope to be in sync around TeXLive 2018.
Different OS can have different i
nd aims to be
compatible with luatexjit ffi.
For luajit ffi see
http://luajit.org/ext_ffi.html
The main difference with standard luajit is that by default jit.off()
in luajittex.
--
luigi
___
If your question is of interest
; manual with some more
> details.
>
> - An old tracker item with respect to control over spacing around math
> was revived and
> has resulted in mathsurroundmode (one can wonder how useful this is).
>
> - We improved the resolution detection in included jpeg images.
>
>
(one can wonder how useful this is).
- We improved the resolution detection in included jpeg images.
- An ffi library has been added to luatex so that it is more in sync
with luajittex. This
permits easy and flexible loading of libraries. Our policy is to
make luatex as lean
as possible
ou can set in
the first line of the document. From an example I found that you can select
the engine this way.
% engine=luajittex
\starttext
Hello World!
\stoptext
What other parameters can I set this way and what is the syntax to set multiple
parameters?
Cheers,
Henri
engine
synctex
jiton
j
r the parameters which you can
>>> set in the first line of the document. From an example I found that you
>>> can select the engine this way.
>>>
>>> % engine=luajittex
>>> \starttext
>>> Hello World!
>>> \stoptext
>>>
>>
=luajittex
\starttext
Hello World!
\stoptext
What other parameters can I set this way and what is the syntax to set multiple
parameters?
Cheers,
Henri
engine
synctex
jiton
jithash
directives
trackers
experiments
epub
ctx|ctxfile
interface
plus for scite
language
Bump
On 01/09/2017 01:49 PM, Henri Menke wrote:
> Dear list,
>
> I cannot seem to find the documentation for the parameters which you can set
> in the first line of the document. From an example I found that you can
> select the engine this way.
>
> % engine=luajittex
Dear list,
I cannot seem to find the documentation for the parameters which you can set in
the first line of the document. From an example I found that you can select
the engine this way.
% engine=luajittex
\starttext
Hello World!
\stoptext
What other parameters can I set this way and what
On 2016-11-19 20:48, Rik Kabel wrote:
This was submitted over a year ago, but probably got lost in the
run-up to the 2015 annual meeting. It is still a problem with ConTeXt
ver: 2016.11.18 22:20 MKIV beta fmt: 2016.11.19 int: english/english
luajittex, 1.0.1. I am happy to provide a pdf
This was submitted over a year ago, but probably got lost in the run-up
to the 2015 annual meeting. It is still a problem with ConTeXt ver:
2016.11.18 22:20 MKIV beta fmt: 2016.11.19 int: english/english
luajittex, 1.0.1. I am happy to provide a pdf and log file, or other
traces
be sure, just give
context --make ; contextjit --make ;mtxrun --script plain --make ;
mtxrunjit --script plain --make
every time you change something (ie new version of luatex , luajittex
, context and so on)
--
luigi
_
1 - 100 of 224 matches
Mail list logo
